OPC UA学习
OPC UA
OPC UA ——Open Platform Communications Unified Architecture => information exchange for industrial communication.
1 Brief History of OPC
发展背景:90年代初期,基于软件的自动化应用的使用迅速增加,它依赖于windows电脑进行可视化和控制,这需要每个自动化设备必须有特定的windows驱动程序,以便与运行在PC上的HMI和SCADA软件交换自动化数据,也产生了不同的通信协议和接口,导致不仅自动化数据不易获取,而且将这些数据传递到更高层次的系统也不容易。
初期:为解决以上问题背景,自动化工程师与公司共同制定了一套通信方法——OPC,即经典OPC。经典OPC的思路是:在驱动程序和HMI之间设置一个标准化接口,这样HMI能通过标准接口从任何类型的自动化设备访问数据,而不必知道具体细节。介个标准接口就是OPC服务器,HMI则是OPC客户端。经典OPC采用微软的组件对象(COM)通信框架,它能使不同的应用程序在同一PC上相互通信,还有分布式COM/DCOM,使运行在同一网络上的两台独立PC上的应用 程序能够进行通信。
OPC传递的数据类型:
- OPC 数据访问接口 —— OPC DA 收集实时读取、写入和监控过程变量;
- OPC 历史访问接口 —— OPC HA 提供对已储存数据访问;
- OPC 报警&事件接口 —— OPC A&E 接受事件和报警通知;
发展:经典OPC的服务器/客户端必须在windows环境下工作,随着Linux设备、嵌入式设备,传感器、智能手机的发展,迫切需要一个能够独立于操作系统的标准;同时,经典OPC不能用于互联网通信,这并不是未来的发展方向。
ENTER OPC UA :基于在发展中经典OPC面临的问题,OPC根据需求彻底改变了OPC架构,并在2008年发布了第一代OPC UA标准。
OPC UA优点:
- Cross Platform& Internet Ready:OPC UA 消除了对COM/DCOM的依赖,并要求所有的OPC UA应用可在不同平台部署,包括PLC、嵌入式设备、网关、web应用、手机… ;能够连接互联网且防火墙友好,因为能够使用https协议
- Complex Information Model :
- Service Oriented Architecture: 面向服务的体系结构 :在诸如modbus这样的协议中,数据交换基于来回传输的比特和字节,这并不是一种用户友好的通信方式。相比之下,在OPC UA服务器中,以方法的形式公开服务,客户端可以使用这些方法从服务器请求信息,这些方法可以用于执行管理任务,定义服务器方法,也可以用来访问实际的自动化数据,如readTag和writeTag,极大的简化了系统开发与维护工作:
- Simplified IT Integration 简化IT集成 :
OPC UA is not a protocol:OPC UA客户端通常连接用于访问其他服务器的系统,利于公开自己的系统信息的服务器,OPC UA与其他通信协和经典OPC相比,解决完全不同的问题
OPC UA标准:
关于OPC UA的标准,OPC基金会主要工作内容为:
- Data Modelling : 该标准的实施者将如何描述服务器要公开的数据;
- Transportation Mechanism : 如何在客户端和服务器之间传输数据:
- 第一种是二进制的TCP协议,在需要高性能的场所表现良好;
- 将传输映射到现有的互联网标准,如http/XML/Web服务器,对网络通信很有效;
2 Introducing OPC UA Information Modelling
Why?
Data Modelling是OPC UA的关键技术之一,使其非常适合成为工业IoT的标准,为什么数据建模对工业物联网如此重要?
- 随着工业物联网通信标准的引入,在自动化信息流动与控制中通信已经不再是初期严格的金字塔形式,而是分散灵活的网络形式的相互通信。所有的组件都可以从其他组件收集信息,调整优化自己,这就要求信息呈现的一致性,如在交互式系统中表示信息的方式与在现场传感器中表示信息的方式相同。因此,信息模型对于工业IoT至关重要。
- 因为所有这些组件本质上都是复杂系统,无论使用何种信息建模方法,都必须允许以数字的方式表示这些生产资产的全部复杂性,这就是OPC UA信息建模的作用:以标准化的方式描述生产资产的组件。如此,任何使用其信息的组件都能获得基础资产的整体视图。最终,工厂或机器能够与工业Iot生态系统的其余部分互联,以标准化的方式公开信息数据。
How?
该如何使用OPC UA表达非常复杂的信息?我们习惯与使用简单的数据类型,例如:用单个浮点变量表示温度。为此,引入地址空间的概念。
地址空间通常表示计算机系统中的任何类型的信息,我们需要内存中的空间来保存数据,即地址空间。现在用来表示地址空间中的简单信息,只需要创建一个变量,并将其表示或者名称提供给任何对读取或写入其值感兴趣的客户机,标识通常是一个在整个地址空间中唯一的字符串变量,如图中的温度。
Node:为了使用地址空间来表示复杂信息,OPC UA就必须以一种特殊的方式组织数据,具体来说就是,OPC UA没有使用类似温度这样的名称来表示一个浮点变量,而是使用一组由单个名称或者标识符表示的不同类型的变量。这些由一组数据组成的一个名称的表示称为**节点(A Node)**,是OPC UA的基本信息单元,在OPC UA中其他类型的数据都是由节点(Node)构成的.
Node的构成:首先是节点本身的信息,如其节点名称或者标识,这些也被称为节点属性;其次是存放实际数据与信息(如温度等);之后还有与之相关的其他节点的信息(引用)。OPC UA信息模型将是这些节点及其引用的集合。
OPCUA不使用简单的字符串变量名表示节点,NODE ID由三部分组成:namespace uri; identifier data type;indentifier。由于名称空间过长,OPC UA服务器中实际的命名空间储存在一个表中,所以只需要制动它在表中的索引,就可以将节点ID简化。
3 OPC UA Information Modelling Framework
定义了节点,是OPC UA的基本信息单位,用来构建其他类型的信息,你需要用节点创建变量、方法和对象,然后连接他们,以建立机器的完整信息结构,设备或传感器。
OPC UA Information Model Basic:建立信息结构的唯一目的是让另一个机器/程序使用它,所以必须建立有关于如何建立和呈现信息的规则,以便于使用OPC UA的所有机器和应用程序对星系的解释存在一致性。因此,OPC基金会正式定义了基本节点类以及节点该由什么组成。
基本节点类指定所有节点必须提供的特诊,这些特诊是每个节点都有且唯一的标识:
并从一个基本节点类模板派生出八种特殊类型的基本节点类:
例子:
4 使用使用.NET创建模型和OPC UA服务器
- 使用XML创建OPC UA信息模型
- 编译模型以生成NodeSet2文件和C#代码;
- 使用该模型在.NET中创建一个OPC UA服务器;
- 最终创建一个OPC UA客户端使用信息;
对于OPC UA服务器和客户端应用程序,将使用OPC基金会提供的OPC UA .NET标准SDK。
如何为复杂系统设计定制的OPC UA信息模型?该过程包括几个步骤,目的是生成NodeSet2.xml文件,NodeSet2是OPC UA标准的一部分文件格式,所有OPC UA兼容的编程语言SDK使用该文件为目标OPC UA生成代码,并填充其地址空间。
生成NodeSet2文件的三种主要方法:
- 直接使用文本编辑器键入;
- 使用图形化的OPC UA模型设计工具,设计模型并自动生成NodeSet2文件以及C/C++/C#代码;
- 使用9个OPC UA标准XML设计模型,允许更直观的设计模型;OPC基金会提供了UA模块编译器等工具,它可以将你在xml中设计的模型编译成NodeSet2.xml,并C#类,以便导入到.NET或OPC UA服务器;该基金会还提供了xml模式定义文件,以帮助指导你的自定义模型设计过程,并提供语法检查和自动识别功能。(compiles your module design in xml file into NodeSet2.xml and also produces C# classes for importing into a .NET or OPC UA server. The foundation also provides xml schema definition files to help guide your custom model design process with syntax cheaking and auto comliection)
**方法3实现步骤: **
构建UML图,建立项目中各对象彼此间关系;
设计xml模型:
- 首先将模型设计作为整个xml程序的最外层:
1
2
3
4
<opc:ModelDesign>
<!--程序主体-->
</opc:ModelDesign>- 在模型设计开始标签中定义命名空间(将一种模型设计与OPC基金会提供的XML模式定义文件相关联的方法)
1
2
3
4
5
6
7
8
9
10
11
12
<opc:ModelDesign
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:opc="http://opcfoundation.org/UA/ModelDesign.xsd"
xmlns:ua="http://opcfoundation.org/UA/"
xmlns:uax="http://opcfoundation.org/UA/2008/02/Types.xsd"
xmlns="http://opcfoundation.org/BatchPlant"
TargetNamespace="http://opcfoundation.org/BatchPlant"
>
<!--程序主体-->
</opc:ModelDesign>- 对工程中有的泛型对象:传感器(温/湿度,力,位移…);执行器(电磁阀,开关…);电机;等等
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26<!--
Define generic base types for the various controllers, sensors and actuators used in the model.
-->
<opc:ObjectType SymbolicName="GenericSensorType" BaseType="ua:BaseObjectType">
<opc:Description>A generic sensor that read a process value.</opc:Description>
<opc:Children>
<opc:Variable SymbolicName="Output" DataType="ua:Double" ValueRank="Scalar" TypeDefinition="ua:AnalogItemType" />
<opc:Property SymbolicName="Units" DataType="ua:String" ValueRank="Scalar" AccessLevel="ReadWrite" />
</opc:Children>
</opc:ObjectType>
<opc:ObjectType SymbolicName="GenericActuatorType" BaseType="ua:BaseObjectType">
<opc:Description>Represents a piece of equipment that causes some action to occur.</opc:Description>
<opc:Children>
<opc:Variable SymbolicName="Input" DataType="ua:Double" ValueRank="Scalar" TypeDefinition="ua:AnalogItemType" AccessLevel="ReadWrite" />
<opc:Variable SymbolicName="Output" DataType="ua:Double" ValueRank="Scalar" TypeDefinition="ua:AnalogItemType" AccessLevel="ReadWrite" />
</opc:Children>
</opc:ObjectType>
<opc:ObjectType SymbolicName="GenericMotorType" BaseType="ua:BaseObjectType">
<opc:Description>A generic motor.</opc:Description>
<opc:Children>
<opc:Variable SymbolicName="Speed" DataType="ua:Double" ValueRank="Scalar" TypeDefinition="ua:AnalogItemType" AccessLevel="ReadWrite" />
</opc:Children>
</opc:ObjectType>- 继承泛型对象定义工程中需要使用的具体的类型;
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25<!--
Define concrete types for the various controllers, sensors and actuators used in the model.
-->
<opc:ObjectType SymbolicName="LevelIndicatorType" BaseType="GenericSensorType">
<opc:Description>A sensor that reports the level of material in a container.</opc:Description>
</opc:ObjectType>
<opc:ObjectType SymbolicName="LoadcellTransmitterType" BaseType="GenericSensorType">
<opc:Description>A sensor that reports the weight of an object.</opc:Description>
<opc:Children>
<opc:Variable SymbolicName="ExcitationVoltage" DataType="ua:Double" ValueRank="Scalar" TypeDefinition="ua:AnalogItemType" AccessLevel="ReadWrite" />
</opc:Children>
</opc:ObjectType>
<opc:ObjectType SymbolicName="ValveType" BaseType="GenericActuatorType">
<opc:Description>An actuator that controls the flow of material.</opc:Description>
</opc:ObjectType>
<opc:ObjectType SymbolicName="MixerMotorType" BaseType="GenericMotorType">
<opc:Description>An motor for mixing materials.</opc:Description>
</opc:ObjectType>
<opc:ObjectType SymbolicName="ConveyorMotorType" BaseType="GenericMotorType">
<opc:Description>An motor for moving finished product.</opc:Description>
</opc:ObjectType>- 为项目中的每个元素定义具体的类型;
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105<!--
Define concrete types for the components contained in the Batch Plant.
These middle tier types could be omitted and declared as folders within the boiler type.
However, doing so would not produce a strongly typed class.
-->
<opc:ObjectType SymbolicName="Silo1Type" BaseType="ua:FolderType">
<opc:Children>
<opc:Object SymbolicName="Silo1LevelIndicator" TypeDefinition="LevelIndicatorType" SupportsEvents="true">
<opc:BrowseName>LI001</opc:BrowseName>
</opc:Object>
<opc:Object SymbolicName="Silo1DischargeValve" TypeDefinition="ValveType" SupportsEvents="true">
<opc:BrowseName>Valve001</opc:BrowseName>
</opc:Object>
</opc:Children>
<opc:References>
<opc:Reference>
<opc:ReferenceType>ua:HasNotifier</opc:ReferenceType>
<opc:TargetId>Silo1Type_Silo1LevelIndicator</opc:TargetId>
</opc:Reference>
</opc:References>
</opc:ObjectType>
<opc:ObjectType SymbolicName="Silo2Type" BaseType="ua:FolderType">
<opc:Children>
<opc:Object SymbolicName="Silo2LevelIndicator" TypeDefinition="LevelIndicatorType" SupportsEvents="true">
<opc:BrowseName>LI002</opc:BrowseName>
</opc:Object>
<opc:Object SymbolicName="Silo2DischargeValve" TypeDefinition="ValveType" SupportsEvents="true">
<opc:BrowseName>Valve002</opc:BrowseName>
</opc:Object>
</opc:Children>
<opc:References>
<opc:Reference>
<opc:ReferenceType>ua:HasNotifier</opc:ReferenceType>
<opc:TargetId>Silo2Type_Silo2LevelIndicator</opc:TargetId>
</opc:Reference>
</opc:References>
</opc:ObjectType>
<opc:ObjectType SymbolicName="Silo3Type" BaseType="ua:FolderType">
<opc:Children>
<opc:Object SymbolicName="Silo3LevelIndicator" TypeDefinition="LevelIndicatorType" SupportsEvents="true">
<opc:BrowseName>LI003</opc:BrowseName>
</opc:Object>
<opc:Object SymbolicName="Silo3DischargeValve" TypeDefinition="ValveType" SupportsEvents="true">
<opc:BrowseName>Valve003</opc:BrowseName>
</opc:Object>
</opc:Children>
<opc:References>
<opc:Reference>
<opc:ReferenceType>ua:HasNotifier</opc:ReferenceType>
<opc:TargetId>Silo3Type_Silo3LevelIndicator</opc:TargetId>
</opc:Reference>
</opc:References>
</opc:ObjectType>
<opc:ObjectType SymbolicName="MixerType" BaseType="ua:FolderType">
<opc:Children>
<opc:Object SymbolicName="LoadcellTransmitter" TypeDefinition="LoadcellTransmitterType" SupportsEvents="true">
<opc:BrowseName>LT001</opc:BrowseName>
</opc:Object>
<opc:Object SymbolicName="MixerMotor" TypeDefinition="MixerMotorType" SupportsEvents="true">
<opc:BrowseName>Motor01</opc:BrowseName>
</opc:Object>
<opc:Object SymbolicName="MixerDischargeValve" TypeDefinition="ValveType" SupportsEvents="true">
<opc:BrowseName>Valve004</opc:BrowseName>
</opc:Object>
</opc:Children>
<opc:References>
<opc:Reference>
<opc:ReferenceType>ua:HasNotifier</opc:ReferenceType>
<opc:TargetId>MixerType_LoadcellTransmitter</opc:TargetId>
</opc:Reference>
</opc:References>
</opc:ObjectType>
<opc:ObjectType SymbolicName="PackagingUnitType" BaseType="ua:FolderType">
<opc:Children>
<opc:Object SymbolicName="PackagingUnitLevelIndicator" TypeDefinition="LevelIndicatorType" SupportsEvents="true">
<opc:BrowseName>LI004</opc:BrowseName>
</opc:Object>
</opc:Children>
<opc:References>
<opc:Reference>
<opc:ReferenceType>ua:HasNotifier</opc:ReferenceType>
<opc:TargetId>PackagingUnitType_PackagingUnitLevelIndicator</opc:TargetId>
</opc:Reference>
</opc:References>
</opc:ObjectType>
<opc:ObjectType SymbolicName="ConveyorType" BaseType="ua:FolderType">
<opc:Children>
<opc:Object SymbolicName="ConveyorMotor" TypeDefinition="ConveyorMotorType" SupportsEvents="true">
<opc:BrowseName>Motor02</opc:BrowseName>
</opc:Object>
</opc:Children>
<opc:References>
<opc:Reference>
<opc:ReferenceType>ua:HasNotifier</opc:ReferenceType>
<opc:TargetId>ConveyorType_ConveyorMotor</opc:TargetId>
</opc:Reference>
</opc:References>
</opc:ObjectType>- 声明batch plant类型,以及不同组件之间的所有引用。在组件之间添加引用需要对其进行重写。被覆盖的节点只需要关心正确的NodeType和SymbolicName;所有其他的 参数都是从原始声明中初始化的。任何被明确指定的参数 替换原始声明,并且即使原始声明被改变也会被使用。被改变也会被使用。
- 申明一个batch plant的实例;
- 将实例链接到对象文件夹。
编译上一步的模型到NodeSet2.xml文件,并生成C#代码导入到.NET OPC UA服务器
使用UA-ModelCompiler编译器,并生成为release版解决方案,可以看到bin/Release/Opc.Ua.ModelCompiler已经生成;
根据Opc.Ua.ModelCompiler提示,在Opc.Ua.ModelCompiler所在目录下打开命令行并编写运行编译指令:
1
.\Opc.Ua.ModelCompiler.exe -d2 D:\files\Area\learn\C#\CompilerOPC_UA\modeldesign\ModelDesign.xml -cg D:\files\Area\learn\C#\CompilerOPC_UA\modeldesign\ModelDesign.xml -o D:\files\Area\learn\C#\CompilerOPC_UA\modeldesign -console -version v104
成功生成了BatchPlant.NodeSet2.xml文件以及预定义的UA节点BatchPlant.PredefinedNodes.uanodes文件。
基于Opc.Ua.ModelCompiler生成的信息模型在.NET中创建一个OPC UA服务器:
- 在visual studio中创建一个windows窗口(WindowsFormsApp(.NETFramework))项目;
- 利用NuGet安装OPC UA SDK
5 OPC UA是如何工作的
OPC UA支持两种通讯协定,这两种通讯协定的差异只有URL的不同,二进制通讯协定是opc.tcp://Server,而Web服务的通讯协定是http://Server,其他情形下,OPC UA对应用程序接口的作业完全透明,其他作业不受OPC UA的影响。
二进制通讯协定的效率最高,其overhead也最少,让需要的资源最小化(不需要XML解析器、SOAP及HTTP,对嵌入式系统格外重要),提供最佳的互操控性(在实现时,二进制通讯协定提供较少的自由度),使用任意选取的TCP通道,可以较容易的进行隧道协议,也可以从透过防火墙开启。
Web服务(SOAP)通讯协定可以支援许多不同的工具(包括Java环境或是.NET环境的工具),使用标准HTTP(S)埠,可以和防火墙共同使用。
所有的实现方式都支援二进制通讯协定,但只有用.NET实现的设备才支援SOAP。
OPC UA规范 属于多部分的规范,包括了以下部分:
- Concepts
- Security Model
- Address Space Model
- Services
- Information Model
- Mappings
- Profiles
- Data Access
- Alarms and Conditions
- Programs
- Historical Access
- Discovery
- Aggregates
- PubSub
OPC UA面向服务的通信架构:
以制造业组织为例:其主要目标是尽可能提高生产效率的同时提供优质产品,为实现这个目标,需要将许多不同的组件整合在一起,使他们能够轻松的交换信息和指令:
因此,我们如何确保在开始的时候,首先意识到这个工厂中的每个组件实际上都在提供服务,无论是机械臂将货物装卸还是跟踪和记录所有活动mes。
例如:机械臂如何执行其工作的内部逻辑,不需要通过其他组件详细了解,事实上,机械臂的所有内部功能都可以被抽象出来,而可以暴露给其他组件的是机械臂可以执行的功能或服务的列表,以及其他组件如何调用这些服务的说明。这种通信架构旨在通过让参与的组件相互提供服务来协调操作,以实现一个共同的目标,这种方式被称为面向服务的。
opcua通过定义抽象服务,如读、写、浏览、订阅和方法调用,为工业应用提供这种面向服务的架构,以暴露底层设备或设备功能。这样,当工业设备和应用供应商在其产品上实施OPC UA时,只是通过OPC UA服务开放了一个标准化的读写接口,现在这使得来自不同供应商的各种工业系统能够无缝地交换信息,而不必理解内部信息,如寄存器、命令等,这是传统上难以实现的,如modbus、profibus和设备网等工业自动化技术。
使用OPC UA将业务背景与闭环控制相结合: 生产程序通常是通过传感器向控制器提供输入,然后在硬接线控制回路中向执行器发送适当的信号来执行的,如果说客户的产品要求超出了标准生产程序,那么你就必须停止生产,重新配置相关的生产设备,有时还要对PLC重新编程,所以OPC UA最佳服务导向架构所实现的,是为外部系统提供机会,调用机器的方法或服务,以指示它做一些事情,这使得生产重新配置,自动化。这种重新配置的界面,延伸到了控制系统领域之外的IT和商业软件,这使得控制环路可以由商业环境驱动,这种情况有些人称之为itot融合,简而言之,opca服务器提供方法或服务,当opcwa客户端希望访问数据或向服务器发送指令时,可以调用这些方法或服务。为了促进这种互动,opcwa有一种机制,使客户能够在本地发现opecua服务器,或者在网络上询问它们,以了解它们提供的服务,连接到它们,使用它们的服务,然后再断开连接。
**OPC UA的实施分层: ** opc ua的面向服务的体系结构建立在不同的逻辑层次上,所有opcua服务都是抽象的方法描述,在一个层次上定义,而数据传输和编码机制则在另一个层次上定义,这意味着,要由opcua技术的技术开发人员使用opc ua技术映射将这些定义的服务映射到他们选择的传输协议上,我们将在本系列的后面讨论。然后,opcua通信平台与用户应用程序代码的接口就留给了编程环境和SDK开发者,正如你可能已经猜到的那样,这种关注点的分离是为了证明opca标准的未来性,以便它不依赖于任何一种传输机制。
OPC UA请求-响应模型:OPC UA服务是基于请求响应形式的通信,这意味着要发生信息交换,需要有两个参与者,一个是客户,一个是服务器。
客户负责发起通信,所以当客户对从服务器上读取数据感兴趣时,它就会发送一个请求,服务器会处理这个请求,然后返回一个响应。
为了实现这种信息交换,作为OPC UA客户端的设备或应用程序和作为OPC UA服务器的设备或应用程序都需要实现一个OPC UA通信栈,这个实现可以是C/C++, java,nodejs或doTnet。但是作为一个应用程序,你不需要处理这些问题。在这种情况下,OPC UA通信平台的作用是对这些消息的请求和响应进行编码和解码,但问题是,例如服务器使用dotnetOPC UA栈,而客户端使用node.JS栈, 唯一的要求是,必须使用相同的技术来传输消息
这个过程开始于OPC UA的客户端,客户使用OPC UA的sdk或api来提交服务请求,如’读‘服务请求,如上所述,OPC UA没有规定sdk或api必须如何与用户应用程序代码接口,但通常sdk或api会提供与规范相对应的方法。
then, opcase平台接受服务请求,并以符合OPC UA规范的消息格式调用它,以便在网上交换数据,然后使用两个平台通用的传输机制将服务请求传输到服务器端堆栈,我们很快就会讨论opca客户端如何找出要使用的传输机制。之后在另一端,OPC UA服务器收到服务请求,对其进行解码,找到要执行的服务,执行请求的操作,然后发送响应消息和操作状态。
OPC UA请求和响应头文件:和大多数通信机制一样,每当提交一个服务请求时,它必须伴随着额外的信息,以请求头的形式提供请求的背景,服务器使用响应头为其响应提供背景,一个OPC UA服务请求有一个请求头,而其服务响应有一个响应头。
建立一个有状态的OPC UA客户-服务器连接
OPC UA服务:
发现服务集:
安全通道服务集
节点管理服务集
视图服务集
查询服务套装
属性服务集
方法服务集
监测项目服务集
注:
.NET Framework 与 .NET Core 的区别与联系:
.NET Framework:支持Windows和Web应用程序。今天,您可以使用Windows窗体,WPF和UWP在.NET Framework中构建Windows应用程序。ASP.NET MVC用于在.NET Framework中构建Web应用程序。
.NET Core:是新的开源和跨平台框架,可为所有操作系统(包括Windows,Mac和Linux)构建应用程序。.NET Core仅支持UWP和ASP.NET Core。UWP用于构建针对Windows和移动应用程序的Windows 10。ASP.NET Core用于构建基于浏览器的Web应用程序。
SDK:Software Development Kit (软件开发工具包)。是一个覆盖面相当广泛的名词:一般都是一些软件工程师为特定的软件包、软件框架、硬件平台、操作系统等建立应用软件时的开发工具的集合,通俗讲就是第三方服务商提供的实现产品软件某项功能的工具包。